Hi all, I am after some general comments and advice on how deep do you need to go with a policy around email or any technology/IT service in general? Some of the example “email policies” I found on the Internet are so vague and short, and give examples of: “all mail traffic will be monitored; employees are expected to use email sensibly, with limited private use acceptable in non-work hours”. But to me, there are so many issues in email management that I wasn’t sure if these are typically documented in policy, or documented somewhere else. As I have never written a policy before, I don’t know what needs to go in it, and what needs to go in other documentation, or what this other documentation is called. For example, if an email accounts receive sensitive data – there is surely a duty to only allow users access to that mailbox who need access to it, and there is a duty to from time to time audit who has access to the mailbox set via AD, or who has access to the mailbox set via delegate rights, check they are applicable, or any inappropriate entries remove. Would this be documented in an email policy, or in some other kind of document? For example if users have a responsibility to check delegate rights to their mailbox, do you need to tell them this in the policy? Same for users with “send as” rights, if they have send as rights, there’s accountability issues in that you could not readily identify who is sending the email if say 15 people have send as permissions for a given mailbox. But do you need to put a point in the email policy around send as rights, or not? i.e. send as rights will only be granted where there is a business need that demonstrates send of behalf of is not applicable? Mailbox retention – does the policy need to state we will only keep mailbox of ex employees for x amount of days. Does that need to go into a policy, or is it just done? Just some general advice on the above on what typically goes in a policy, and what doesn’t. And if it doesn’t go in the policy, where does it go?

From my experience, such documents are vague for the purpose of allowing operational flexibility - so instead of documenting specific teams/roles who might access data, a term like "nominated persons" or "employees" might be used instead. Technical specifics are not necessarily relevant for such a document as it shouldn't need to be re-written if a feature is added in a service pack or you change products, for example. The key part is that the document is usually submitted to company lawyers who aren't going to be technical but will understand better than us the relevant legislation and how it applies to the policy and what is/isn't required in the document. Around the policy, procedures for the implementation of the policy (such as who is allowed to grant/check access, technical procedures) would be handled separately and these may also need to be checked to ensure they comply with the policy. I know this is vague but the legislation is different around the world so requirements of what should/shouldn't be in such a policy aren't set it stone. For example in the UK we are bound by the Data Protection Act, RIPA etc. SteveSteve Goodman Check out my Blog for more Exchange info or find me on Twitter

From my experience, such documents are vague for the purpose of allowing operational flexibility - so instead of documenting specific teams/roles who might access data, a term like "nominated persons" or "employees" might be used instead. Technical specifics are not necessarily relevant for such a document as it shouldn't need to be re-written if a feature is added in a service pack or you change products, for example. The key part is that the document is usually submitted to company lawyers who aren't going to be technical but will understand better than us the relevant legislation and how it applies to the policy and what is/isn't required in the document. Around the policy, procedures for the implementation of the policy (such as who is allowed to grant/check access, technical procedures) would be handled separately and these may also need to be checked to ensure they comply with the policy. I know this is vague but the legislation is different around the world so requirements of what should/shouldn't be in such a policy aren't set it stone. For example in the UK we are bound by the Data Protection Act, RIPA etc. Steve Steve Goodman Check out my Blog for more Exchange info or find me on Twitter Thanks Steve. My concern is if users are expected to check delegate rights for security reasons, and they dont do it, and user X who is now in a different department, can still access this mailbox and its sensitive content, and then leaks it to some newspaper, but it isnt documented anywhere in policy that users should check and remove unneccesary ACL to mailboxes they own... then its the company at fault for not defining the procedure? Thats just one example. But stale unused/monitored mailboxes (still getting SPAM and filling up in size), users autoforwarding to their hotmail account, people sending malicious email as they have send as rights, ex employees mailboxes sitting on the exchange server who file a subject access request and the company gets fined by the ICO as they have no right to have his mailbox as he left 3 years ago etc etc. If these things arent to be documented in an email policy, what are they documented in? How do people know about them, and the corporate rules on these things? Whats this document called? Policies do seem vague I agree, and dont seem to cover a lot of areas.

Perhaps a good start would be to publicise the requirements of the Data Protection Act and how they relate to your users, and then provide "best practises" for them to follow that align them with it. I'm no lawyer(!!) but my understanding is that the user/employee does have responsibilities under the DPA as well as the company. For example, when users ask about forwarding there email we make it clear that should they do that, the entire responsibility for security of the message (which may contain subject matter covered by the DPA) is put on their shoulders.. and that there isn't really any reasonable way they can verify that they are keeping their messages secure, as they could be intercepted in transit and they cannot vouce for the security of the free email service they are using (or how EU Safe Harbour legislation applies to their free, personal, email account, whereever it is).. So perhaps a good start would be ensuring your users know the legislation (in plain terms) and you provide guidance to them on how to comply. With regards to employees who have left, I would suggest making proposals to your IT director that can be taken up to an executive level for a decision - this might be a one/two side document stating the justification for removal of accounts (not just mailboxes!), the procedure for archiving and disposing of them in a timely fashion (based on the business requirements, but taking into account operational requirements like freeing up storage). Finally it should be made clear in your AUP that the ownership of the account is the employer's, not the employee. Again.. I am not a lawyer! But.. As I understand it under RIPA there is a case that access to a user account/mailbox after a person has left is valid for purposes like continuity of business, so long as anything clearly personal is not touched. HR should know, agree with and support this policy. To avoid such issues though, consider using role-based/shared mailboxes that can seperate business information from the more personal nature of a user mailbox. This way, when someone leaves it is easier to remove their account quickly without impacting the business. Looking back when we performed a similar exercise, the driving factor was how legislation would impact us. So, it may be worth finding out what you need to care about and what you can safely ignore from legal advisors who know the area well. Once that's established you should have some clear goals on where you need to communicate with users, what to put into policies and what to provide guidance/documentation on. SteveSteve Goodman Check out my Blog for more Exchange info or find me on Twitter